There is a large community of Tcl developers who provide packages of Tcl commands to the programming community. Tcl stands for “Tool Command Language” that has two main components: 1) a scripting language, and 2) an interpreter. Although similar to other UNIX shell languages, Tcl distinguishes itself from other shell languages in that it is easy to add or embed the Tcl interpreter into an application. The Tcl can then be utilized to configure and execute other programs and to customize the programs. For example, Tcl allows a programmer to structure an application as a set of primitives that can be composed with a script to best suit the needs of a user. Tcl also allows other programs to have program control over other applications.
Two examples of these packages are ActiveTcl and Tcom. ActiveTcl is a COM wrapper for the Tcl shell and provides access to Tcl from COM clients. Tcom provides access to COM interfaces from Tcl. Unfortunately, Tcom only works on Windows based hosts. Similar packages exist for Perl (e.g., ActivePerl), but these packages are also only available on Windows hosts. In addition, the client and server must both exist on the same Windows host.
COM interfaces can be accessed natively from scripting languages such as VBScript and JavaScript, but only when executing on a Windows personal computer. Alternative programming APIs extend the client Tcl interpreter with proprietary code and requires custom binaries to be shipped for each target platform. In addition, development is required for each target platform.
Customers and users of testing equipment may have a large installed base of UNIX based workstations. These customers have a significant investment in test equipment, existing software testing tools, and test configurations. These testing tools are often developed by the clients in a language such as Tcl or Perl and run on UNIX workstations. The assignee of the present invention has developed a Windows based tester. Consequently, it is important that there be a mechanism to allow these existing tools and test configurations to access the Windows based tester. Unfortunately, these existing tools and test configurations currently cannot communicate with a test system having a COM interface.
The re-development of these existing tools and test configurations, as can be appreciated, is expensive, time-consuming, and very inefficient.
Consequently, it is desirable to have a mechanism for allowing a scripting language (e.g., Tcl or Perl) in a first platform (e.g., UNIX) to access interfaces of a distributed object model that is specific to a second platform (e.g., a Windows platform).